The primary protocol for congestion control in the Internet is TCP. The rapid growth of applications and services over the Internet has made the performance of TCP a major issue in data networking. TCP performs its own data recovery and flow control, and makes no assumption on how the network processes the data it sends. TCP congestion control as well as error recovery are implemented by a sliding window. The TCP flow control mechanism is meant to slow down the source rate when the network becomes congested, but currently, TCP has no direct way of knowing when the network is congested. It can only indirectly detect congestion by keeping track of how many packets are lost. When packets do get lost, the loss indicates that some queue in the network might have overflowed. Every time TCP detects a packet loss, it reduces its source rate to alleviate the congestion that could have caused the packet loss.
In a high-latency network environment, the window flow control mechanism of TCP may not be very effective because it relies on packet loss to signal congestion, instead of avoiding congestion and buffer overflow. The basic problem is that TCP does not communicate directly with the network elements to be given its optimal or assigned traffic rate. By the time the TCP source starts decreasing its rate because of packet loss, the network has already been overly congested. This problem exists because the design of TCP currently only considers the flow control needs of the receiver. It does not consider the flow control needs of intermediate hops in the network. Overflow in the network itself would be detected by the sender through timeouts or through acknowledgment arrival patterns. This model has problems coping with shared multi-hop networks, where the cause of packet loss is within intermediate hops in the network.
Thus, it is generally accepted that there is a limit to how much control can be accomplished by the congestion control mechanisms in the end systems. Some mechanisms are needed in the routers to complement the endpoint congestion avoidance mechanisms. As a result, network layer enhancements such as scheduling mechanisms (e.g., Fair Queuing) and packet drop policies (e.g., Random Early Detection (RED)) have been proposed which are aimed at improving fairness and throughput.
Ideally, the source should respond to congestion (in the network and at the destination) before it occurs rather than acting when it is too late. Thus, one method to make TCP sensitive to network congestion and buffer overflows is to allow network elements between a source and destination to modify the receiver's advertised window in TCP acknowledgments returning to the source. Through this the network becomes an active (and not a passive) participant in controlling congestion and buffer overflows, similar in spirit to the intelligent congestion control techniques such as RED or RED combined with Explicit Congestion Notification (ECN). Thus, the motivation for TCP rate control and similar schemes, is the need for network control policies which do not necessarily resort to packet discard as the only means for congestion control.
Most of the existing window adjustment schemes are based on heuristics and their performance under a wide range of networking conditions are not clearly understood. The drawback of one scheme (see e.g., R. Satyovolu, K. Duvedi, and S. Kaylanaraman, “Explicit Rate Control of TCP Applications”, ATM Forum Document, ATM-Forum/98-0152R1, February 1998.) is that the optimal setting of the window size to be fed back to the TCP sources, requires accurate knowledge of the round-trip time (RTT) estimates. Also, such information is usually not available at network elements. Another scheme (see e.g., P. Narvaez and K-Y Siu, “An Acknowledgement Bucket Scheme for Regulating TCP Flow Over ATM”, Proc. Globecom '97, Phoenix, Ariz., 1997.) entails too much per-flow state at access nodes, essentially requiring per-flow window tracking.
In view of the foregoing, it would be desirable to provide a technique for data packet flow in a network which overcomes the above-described inadequacies and shortcomings. More particularly, it would be desirable to provide a technique for controlling TCP rate in a network in an efficient and cost effective manner.